Medical payment system

ABSTRACT

A medical payment system is described in which a provider of medical goods and/or services submits, via telephone or other communications medium, a request for payment amount determination for a patient encounter. A price determination system determines which of a plurality of fee schedules negotiated by the provider applies to the patient encounter and calculates, based at least in part on information entered by the provider, a payment amount for the encounter. In one embodiment, the provider receives the payment amount information while the patient is at the point of service. In one embodiment, the provider may use the system to submit a claim for payment by at least one responsible party.

RELATED APPLICATIONS

Any and all applications for which a foreign or domestic priority claimis identified in the Application Data Sheet, or any correction thereto,are hereby incorporated by reference into this application under 37 CFR1.57.

BACKGROUND OF THE INVENTION Field of the Invention

The present invention is related to payment systems, and, in particular,to medical payment systems.

Description of the Related Art

Payment amounts for medical care in the US are increasingly set byPreferred Provider Organizations (PPO's) that negotiate reduced rateswith medical providers for medical services and goods provided topatients. Agreeing to accept the reduced rates offered by a PPOintroduces a medical provider to the population of patients that areaffiliated with the PPO. Individual medical providers may negotiatecontracts with many different PPO's, each with its own negotiated feeschedule that specifies the contracted payment amount for each medicalgood and service offered by the provider.

Fee schedules are updated when fees change, especially when a negotiatedfee is based on another rate, such as an agreed percentage off ofstandard Medicare rates. Fee schedule updates are typically transmittedto providers as printed pages of updates that can be kept in theprovider's office in binders that may be numerous, unwieldy to handle,and difficult to reference. Attempting to quickly determine which feeschedule is the appropriate one to use for a given patient encounter canbe difficult for the provider, especially when the patient belongs to ahealth plan with access to fee schedules from more than one PPO.

Some PPO's maintain websites that providers can access via computernetwork in order to get payment amount information based on the PPO'scurrent fee schedule, but providers have thus far demonstratedreluctance to access payment information or to submit claims for paymentvia computer. According to one report, only 10% of providers who coulduse the computer to access payment amount information do so. Severalfactors may help to explain this fact: lack of available computerequipment at the time of patient check-out, lack of comfort on the partof the provider in using the computer and interacting with the variousinput requirements and interface styles of the different PPO websites,inability of the PPO website to provide a quick and easy interface toits services, and lack of speed and/or capacity of the provider'scomputer connection, amongst other reasons. Furthermore, having access,by paper or by computer, to individual PPO fee schedules does not helpthe provider determine which PPO fee schedule is appropriate to use fora given patient encounter when the patient's health plan offers accessto more than one PPO fee schedule.

SUMMARY OF THE INVENTION

A medical payment system is described that allows a medical provider tocommunicate by telephone, using voice and/or telephone keypad, to submitinformation about an encounter with a patient and to receive informationabout an associated payment amount owed to the provider for the medicalservices and goods provided. In some embodiments, an interactive voiceresponse system (IVRS) allows the provider and the price determinationsystem to communicate in a manner that is convenient and easilyunderstandable for the provider.

A medical payment system is described that allows a medical provider torequest and to receive payment amount information for an encounter witha patient who belongs to a health plan that comprises one or morenegotiated Preferred Provider Organization (PPO) fee schedules. A pricedetermination system locates an appropriate fee schedule for theencounter and calculates a payment amount for medical goods and/orservices associated with the patient encounter. For health plans thatcomprise a plurality of fee schedules, the price determination systemaccesses information about a hierarchical ranking of the fee schedules.The price determination system selects, from amongst the fee schedulesnegotiated by the provider, the fee schedule that has the highestranking in the hierarchy, and uses the selected fee schedule tocalculate the payment amount for the patient encounter.

In some embodiments, when payment of all or part of the calculatedpayment amount is the responsibility of at least one party or entityother than the patient, the provider may also use the system to submit aclaim to a responsible third party or entity, such as a medicalinsurance company or third party administrator, a medical credit cardaccount, or other source of funds dedicated for payment of the patient'smedical expenses. In one embodiment, information about the calculatedpayment amount can be transmitted to a responsible third party or entityso that payment may be transmitted directly to the provider's bankaccount.

In one embodiment, a healthcare price determination method is described,in which the method comprises: receiving, via telephone, informationabout at least one patient encounter with a medical provider;determining the contracted payment amount associated with the encounter;and communicating via a voice response system the determined paymentamount to at least the medical provider. The price determination methodmay further comprise transmitting information about the payment amountto a responsible party or entity, so that a claim for payment to theprovider may be submitted, and payment may be subsequently transmittedto a bank account associated with the provider.

For purposes of summarizing embodiments of the invention, certainaspects, advantages, and novel features of the invention have beendescribed herein. It is to be understood that not necessarily all suchaspects, advantages, or novel features will be embodied in anyparticular embodiment of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts an overview of one embodiment of a medical payment systemthat comprises a price determination system.

FIG. 2A depicts one embodiment of an eligibility list used by a pricedetermination system.

FIG. 2B depicts one embodiment of a priority list used by a pricedetermination system.

FIG. 2C depicts one embodiment of a provider list used by a pricedetermination system.

FIG. 3 is a flowchart that depicts one embodiment of a medical paymentsystem.

FIGS. 4A and 4B (hereinafter referred to collectively as “FIG. 4”)present a flowchart that depicts one embodiment of an encounterinformation input system.

FIG. 5 is a flowchart that depicts one embodiment of a method todetermine a contracted payment amount for a patient encounter.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

A medical payment system is described in which a provider of medicalgoods and/or services submits, via telephone or other communicationsmedium, a request for payment amount determination for a patientencounter and in which the provider receives via an interactive voiceresponse system (IVRS) information about the requested payment amount. Aprice determination system determines which of a plurality of feeschedules negotiated by the provider applies to the patient encounterand calculates, based at least in part on information entered by theprovider, a payment amount for the encounter, which it communicates toat least the provider. In one embodiment, the provider receives thepayment amount information while the patient is at the point of service.In one embodiment, the provider receives information about a firstportion of the payment amount, if any, for which it is the patient'sresponsibility to pay and a second portion of the payment amount, ifany, which is to be paid by another responsible party or entity. In oneembodiment, the provider may use the system to submit a claim forpayment to at least one responsible party or entity.

FIG. 1 depicts an overview of one embodiment of the medical paymentsystem. In brief, FIG. 1 depicts a system in which a patient 100 goes toa medical provider 110 for medical goods and/or services. An instance inwhich the patient 100 visits the provider 110 and receives medical goodsand/or services can be called a patient encounter. The medical provider110 communicates by telephone or by other communications method with aprice determination system 115 in order to determine the payment amountdue to the provider 110 for the encounter. The price determinationsystem 115 calculates a payment amount, as will be described in greaterdetail below and communicates the amount to the provider 110 and, ifapplicable, to one or more parties or entities that are responsible forpaying the provider 110. In one embodiment, the price determinationsystem 115 communicates the payment amount back to the provider's office110 immediately so that the patient 100 can pay the provider 110 beforeleaving the provider's office 110. In one embodiment, when some or allof the payment amount is to be paid by a third-party payor 190, such asa medical insurance company, or from a medical credit card account 195,or is to be paid from a purse 192, as will be described in greaterdetail below, the price determination system 115 communicatesinformation about the payment amount to the payor 190, the purse 192and/or the medical credit card account 195 so that payment may be madedirectly to a bank account 112 associated with the medical provider 110.

Describing FIG. 1 now in more detail, the provider 110 depicted may be adoctor, a pharmacist, a dentist, an optometrist, a hospital, or othermedical practitioner or provider of medical goods or services. Arepresentative of the provider 110, such as a receptionist, billingspecialist, or other assistant, may initiate and execute thecommunication between the provider's office 110 and the pricedetermination system 115, and, for purposes of this description, theterm “provider” will refer to a provider or other person operating onbehalf of the provider in communicating with the price determinationsystem 115.

In one embodiment, the patient 100 presents to the provider 110 amedical plan card 105 that represents the patient's 100 membership in agroup, known for purposes of this application as a client group, thatoffers a medical plan to its members. In one embodiment, access to themedical plan confers upon the patient 100 eligibility to receive medicalcare and/or goods at a contracted reduced rate.

The client group may provide discounted rates on medical goods andservices for their members by building a medical plan from medicalpricing contracts available through one or more Preferred ProviderOrganizations (PPO's). The PPO's negotiate pricing contracts withmedical providers who agree to accept individually determined reducedpayment rates for their goods and services in exchange for access to thepatient base offered by the PPO. In one embodiment, the medicalproviders 110 also agree to accept reduced payment rates in return for aguarantee of immediate or expedited payment for patient encounters. Amedical provider 110 typically contracts with a number of PPO's and maythus have agreed to accept a wide variety of contracted payment ratesfor each given medical good or service. For the provider 110 todetermine the correct contracted rate for the goods and servicesassociated with a given patient encounter is typically a complex andtime-consuming task and often cannot be accomplished while the patient100 is waiting to check out from the provider's office 110. Thus, theprovider 110 may lose the opportunity to receive payment at the time ofservice and may have to expend time and money to bill the patient 100 ata later date and to hope to receive payment without enduring aprotracted delay.

In one embodiment, information on the medical plan card 105 comprises atelephone number that allows the provider 110 to dial and access viatelephone an interactive voice response system (IVRS) that is associatedwith the price determination system 115 and that is configured to acceptand to transmit information about a calculated payment amount for thepatient encounter, as will be described in greater detail with referenceto FIGS. 3-5 below. In one embodiment, the provider 110 communicateswith the price determination system 115 about a calculated paymentamount for the patient encounter using a computer that is configured toaccess a computer network, such as the Internet, to which the pricedetermination system 115 is also connected. In other embodiments, othermethods of communication are used that allow the provider 110 to receivepayment amount information for a patient encounter, including by way ofexample, dedicated communication lines, telephone networks, wirelessdata transmission systems, two-way cable systems, customized computernetworks, interactive kiosk networks, automatic teller machine networks,interactive television networks, and the like.

One advantage of a telephone-based embodiment is the ease of use anduniformity of availability that it offers to the provider 110. Whilecomputers are becoming increasingly common in provider offices,discrepancies still exist in the capabilities of computer equipment andstaff at provider offices. Lack of an available computer at a provider'scheck-out desk, lack of reliable computer network connection, slowtransmission rates, and inability or unwillingness of office staff touse the computer are all conditions that currently exist. In fact,although computer systems for submitting some types of medical insuranceclaims for later payment do exist, statistics indicate that only around10% of provider offices currently choose to make use of such systems.Telephones, on the other hand, are virtually ubiquitous in medicalprovider offices, and office staff are familiar and comfortable withtheir operation.

The ability on the part of the provider 110 to access paymentinformation, whether by telephone or by other communication method, atthe point and time of service represents an improvement over currentsystems in which the provider 110 typically waits three to six monthsfor payment. In some current systems, the provider 110 submits apaper-based request for payment information to a PPO and must wait for awritten response before being able to accurately bill the patient 100.In some current systems, the provider 110 bills the patient 100 astandard rate that may exceed the contracted PPO rate to which thepatient 100 is entitled and that must later be adjusted and refunded. Insuch systems, even if a patient 100 desires to pay at the point ofservice, accurate payment amount information may not be readilyavailable. In embodiments where a patient 100 shares responsibility forpaying the provider 110 with another party or entity, such as a medicalinsurance company 190 or a source of funds 192 for payment of thepatient's medical expenses, communicating with the price determinationsystem 115 at the point of service allows the provider 110 to accuratelyinform the patient 100 of the portion of the total payment amount forwhich the patient 100 is responsible and to request immediate paymentfor that portion.

In one embodiment, communicating with the price determination system 115also allows the provider 110 to submit a claim on behalf of the patient100 to any parties or entities 190, 192, 195 that are responsible to paythe provider 110 for all or part of the payment amount associated withthe patient encounter.

As depicted in the embodiment of FIG. 1, the price determination system115 comprises client-specific data 120, which, when supplemented asneeded by price calculation data 125, allows the price determinationsystem 115 to accurately calculate the contracted payment amount for apatient encounter. In one embodiment, the price determination system 115operates using computer program logic that may advantageously beimplemented as one or more computer modules configured to execute on oneor more processors. For the purposes of this description, computermodules may comprise, but are not limited to, any of the following:software or hardware components such as software object-orientedsoftware components, class components and task components, processesmethods, functions, attributes, procedures, subroutines, segments ofprogram code, drivers, firmware, microcode, circuitry, data, databases,data structures, tables, arrays, or variables.

The client-specific data 120 of the price determination system 115comprises information specific to the medical plan of the client groupto which the patient 100 belongs and instructions about how paymentdetermination is to be carried out for encounters associated with theclient group. The price calculation data 125 comprises information thatmay apply to all or many of the client groups serviced by the pricedetermination system 115 and that may be used for calculating a paymentamount for an encounter involving a patient from any of the clientgroups associated with the price determination system 115. In oneembodiment, client-specific data 120 is implemented as a computermodule.

In one embodiment, client-specific data 120 for a given client group isindexed or accessed via a client group access number 130, and dialingthe telephone number printed on the patient's 100 medical plan card 105automatically connects the provider 110 to the appropriate client groupaccess number 130 for the client group to which the patient 100 belongs.Thus, the price determination system 115 is able to provide paymentinformation for patients 100 from a variety of medical plans using asingle, simple, standardized interface and to quickly access theappropriate information in order to calculate an accurate payment amountfor the patient encounter.

FIG. 1 depicts some examples of the types of client-specific data 120that may be stored and used by the price determination system 115 indetermining the contracted payment amount for an encounter and insubmitting a claim for the determined amount to one or more responsibleparties. In some embodiments, some or all of the client-specific data120 are implemented as computer modules, as was described above.

An eligibility list 135, which will be described in greater detail withreference to FIG. 2A, comprises information about whether a givenpatient 100 is eligible for some, all, or none of the benefits offeredto members of the client group. A provider list 140, which will bedescribed in greater detail with reference to FIG. 2B, comprisesinformation about providers who are affiliated with the PPO's that havecontracted with the client group. A priority list 145, which will bedescribed in greater detail with reference to FIG. 2C, comprisesinformation about a hierarchy of PPO's that make up a medical plan andabout how to determine the correct contracted rate for a provider who isaffiliated with more than one PPO.

Fee schedules 150 stored with the client-specific data 120 of a givenclient group comprise information about how to calculate the paymentamount agreed to by a given provider 110 in affiliation with a givenPPO. In some embodiments, the fee schedules 150 are implemented as oneor more computer modules. In some embodiments, the agreed amounts arefixed and are constant for all providers 110 affiliated with the PPO. Insome embodiments, providers are grouped by their zip codes, andproviders in a given zip code are paid at the same rate. In someembodiments, the payment amounts are calculated as a percentage off theprovider's 110 usual billed rate for the service or good. In someembodiments, the amounts are calculated using standard Medicare rates asa basis. In some embodiments, rates for certain goods or services arecalculated in one way, while rates for other goods or services arecalculated in another way. In some embodiments, a PPO may have arrivedat different agreements with different affiliated providers for variousgoods and services, and information describing these agreements isstored within the fee schedule 150 for the PPO. Thus, in someembodiments, the client-specific data 120 for a given client group maycomprise a fee schedule 150 for each PPO that forms a part of the clientgroup's medical plan.

Fee schedules are updated periodically, often every four to six weeks,in order to reflect changes in a PPO's contracted rates. Using the pricedetermination system 115 to easily access current and accurate paymentamount information at the point of service rather than attempting tolocate the desired information in written format using the numerous andoften unwieldy binders provided by individual PPO's is another advantageoffered to the patient 100 and the provider 110 by the pricedetermination system 115.

Client-specific data 120 for a client group also comprises benefitcoverage/payment rules 155 that provide instructions to the pricedetermination system 115 regarding how the patient encounter paymentamount is to be calculated for the client group's medical plan and howclaims to responsible parties and entities are to be submitted for theclient group's medical plan. In one embodiment, the benefit coverage andpayment rules 155 are implemented as one or more computer modules.Benefit coverage/payment rules 155 will be described in greater detailbelow, still with reference to this figure.

As described above, in addition to the client-specific data 120 indexedby client group access number 130, the price determination system 115also comprises general purpose price calculation data 125 that may beuseful for determining a contracted payment amount for a patientencounter associated with any client group. Some examples of such pricecalculation data 125 are depicted in FIG. 1.

Accurately describing the procedures associated with a patient encountercan be accomplished using Current Procedural Terminology (CPT) codes 160and CPT modifiers 165 that are defined and maintained by the AmericanMedical Association and that are used as an industry standard todescribe over seven thousand different procedures. In one embodiment,each CPT code 160 is associated with a multiplier value that is used inconjunction with information from the fee schedule 150 to calculate thecontracted payment amount. For example, a fee schedule may indicate thatfor providers in a given zip code area, all procedures with CPT codes160 beginning with a “9,” which indicates an office visit procedure, arepaid at a rate of $5.40 per multiplier unit. If an extended officevisit, with CPT code “90028,” has a multiplier value of 8.2, then aprovider 110 in the given area who requests pricing for an extendedoffice visit will be given the PPO-negotiated payment amount of $44.28.In one embodiment, the price calculation data 125 also comprises HealthCare Procedure Codes (HCPC), which use a five-digit alphanumeric systemto identify coding categories not covered by CPT codes.

Other price calculation data 125 that may be stored by the pricedetermination system 115 are ICD-9 codes 170, which are an industrystandard used to describe medical diagnoses, current Medicare rates 175,which may be used in some situations as the basis for a PPO-negotiatedpayment amount, and tables of zip codes 180. Some, all, or none of thesetypes of data, along with other data used by the price determinationsystem 115 to calculate a contracted payment amount for a patientencounter and for apportioning responsibility for paying the paymentamount may be stored as general purpose price calculation data 125. Insome embodiments, some or all of the price calculation data 125 isimplemented as one or more computer modules.

Using information from the client-specific data 120 and any necessaryprice calculation data 125, the price determination system 115 is ableto calculate the appropriate contracted payment amount for the patientencounter.

As was described briefly above, the client-specific data 120 comprisesbenefit coverage and payment rules 155 that instruct the pricedetermination system 115 on how to calculate the contracted paymentamount and, if desired, how to further process the payment amountinformation for a given client group's medical plan. In someembodiments, the benefit coverage and payment rules 155 allow the pricedetermination system to accommodate health plans in which responsibilityfor paying some or all of the contracted payment amount may be sharedwith the patient 100 by a third-party payor 190, a medical credit cardaccount 195, or a medical payment fund 192. The benefit coverage andpayment rules 155 are formulated to suit the needs of the given medicalplan and to allow the price determination system 115 to flexibly servethe needs of a wide variety of medical plans.

As an example, in one embodiment, a client group's medical plan mayprovide access to PPO-negotiated rates for medical goods and servicesthat the patient 100 agrees to pay to the provider 110 in full at thepoint of service. In this example, the benefit coverage and paymentrules 155 may instruct the price determination system 115 to use theclient-specific data 120 and the price calculation data 125 to calculatethe contracted payment amount and to communicate the amount back to theprovider 110 verbally using the IVRS. In some embodiments, options mayalso be provided to send a written copy of the price determination tothe provider 110 via fax transmission and/or to the patient's homeaddress via postal service.

As another example, a client group's medical plan may provide access toPPO-negotiated rates for medical goods and services that the patient 100agrees to pay to the provider 110 in full at the point of service usinga dedicated medical credit card 195. In one embodiment, a medical creditcard 195 is different from a regular credit card in that charges made tothe medical credit card 195 will only be approved if the credit cardcompany receives, prior to the request for approval, verification fromthe price determination system 115 that the charge is for a bona fidemedical expense. In one such embodiment, the medical plan card 105 mayalso be the medical credit card.

In one example of a medical credit card health plan, the benefitcoverage and payment rules 155 may instruct the price determinationsystem 115 to calculate the payment amount for the encounter, to sendpayment amount information to the provider office 110 so that thepatient 100 can pay the provider 110 using the medical plan/credit card105 in the provider's office. The price determination system 115 furthersends verification of the encounter and the payment amount to themedical credit card company 195 so that the medical credit card chargewill be approved. In such an embodiment, the price determination system115 may send a verification message to the medical credit card company195 that comprises patient 100 identification information, provider 110identification information, and the calculated payment amount. When theassociated charge request is received by the medical credit card company195, if the patient identification 100, the provider identification 110,and the payment amount match those received in the verification message,the charge is approved, and payment is sent to the provider's bankaccount 112.

In another example of a medical credit card health plan, in oneembodiment the benefit coverage and payment rules 155 may instruct theprice determination system 115 to calculate the payment amount for theencounter and then to transmit a charge request directly to the medicalcredit card company 195. Once approval of the charge is received by theprice determination system 115 from the medical credit card company 195,the price determination system 115 can transmit this information back tothe provider's office 110.

As another example, a client group's medical plan may provide access toPPO-negotiated rates for medical goods and services in conjunction witha “purse” 192, which, for purposes of this description, is a fund ofmoney that is available for payment of a patient's approved medicalexpenses. In one embodiment, a purse 192 may be funded by the patient100 and/or by the patient's employer. In one embodiment, funds for thepurse are deducted on a pre-tax basis from a patient's 100 paycheck andare available for paying Internal Revenue Service (IRS)-approved medicalexpenses. Some examples of purses 192 and the names by which they areknown are: flexible savings account (FSA), medical savings account,health savings account, and personal care account. In one embodiment, amedical plan card 105 used in conjunction with such a medical plan mayalso serve as a “stored value card.”

In conjunction with this type of health plan, in one embodiment, theclient-specific data 120 may further comprise a list of approved medicalgoods and services, which may be identified by CPT code. The eligibilitylist 135 may further comprise information about an available balance offunds in the patient's purse 192. The benefit coverage and payment rules155 may instruct the price determination system 115 to consult the listof approved medical goods and services to verify that the encounter isassociated with approved goods and services or to calculate an approvedportion of the payment amount, if not all of the encounter's goods andservices are approved. The benefit coverage and payment rules 155 mayfurther instruct the price determination system 115 to verify thatsufficient funds exist in the purse 192 to cover the approved portion ofthe calculated payment amount, and, in one embodiment, to submit a claimto the purse 192 so that funds covering the approved portion of thepayment amount are deducted from the purse 192 and are deposited in themedical provider's bank account 112. In one embodiment, the pricedetermination system 115 can then communicate with the provider's office110 via IVRS and/or fax transmission information about the calculatedpayment amount and about any approved amount paid from the patient'sFSA, or other purse.

In addition to the immediate payment advantage thus afforded to theprovider 110, such a medical payment system also provides an advantageto the patient 100 in that the patient 100 need not first pay out ofpocket for approved expenses and then later submit a written request forreimbursement, but may have the funds deducted from the purse 192automatically.

In another example, the price determination system 115 may calculate thecontracted payment amount on behalf of a third party payor 190 that maybe responsible for paying some, all, or none of the payment amount tothe provider 110. A third party payor 190 may be a medical insurancecompany, a self-insured employer that provides its own insurance for itsemployees, a third-party administrator for a self-insured employer, oranother entity that is responsible for paying some or all of a patient'smedical expenses and that has negotiated for discounted rates availablefrom a set of PPO's. Thus, in some embodiments, in order to correctlydetermine and to apportion responsibility for paying the calculatedpayment amount to the provider 110, the benefit coverage/payment rules155 may describe which medical goods and services are covered by thepayor 190, as well as benefit payment levels for those that are covered.

For example, some medical plans cover well-baby check-ups, while othermedical plans do not. Some plans will pay for 80% of the contractedpayment amount for a basic procedure, but only 50% of certain laboratorytests. Some services, such as chiropractic treatments, may be coveredfor only up to ten visits a year or ten visits per injury. Some planshave an annual maximum that they will pay. Using the benefitcoverage/payment rules 155, client-specific information stored about thepatient in the eligibility list 135, and the calculated payment amount,the price determination system 115 is able to apportion responsibilityfor paying the provider 110 for the patient encounter.

The benefit coverage/payment rules 155 may instruct the pricedetermination system 115 to submit a claim for approved expenses to thethird-party payor 190. In some embodiments, such a claim comprisesinformation desired by the payor, such as, for example, patient 110 andprovider 110 identification, and CPT 160 and ICD-9 170 codes associatedwith the encounter, and calculated payment amount. In some embodiments,the benefit coverage/payment rules 155 will also instruct the pricedetermination system 115 to notify the provider 110 of the claimsubmission and of any payment amount not included in the claimsubmission that remains for the patient 100 to pay.

In other examples, client groups may provide a medical plan that is acombination of the medical plans described above. For example, a healthplan may offer medical insurance coverage 190 in conjunction with an FSApurse 192 that can be used to pay for approved expenses that are notcovered by the medical insurance 190. Or, a health plan may offermedical insurance coverage 190 in conjunction with an FSA purse 192, asabove, with the added feature of a medical credit card 195 that can beused to pay for expenses that are not covered by either the medicalinsurance 190 or the FSA purse 192. The flexible nature of the pricedetermination system 115 together with the expressive capabilities ofthe benefit coverage and payment rules 155 allows the pricedetermination system 115 to serve a wide variety of client groups, eachwith different memberships, providers, PPO affiliations, and healthplans, while providing a universally-available, easy-to-use interface tothe provider 110. In embodiments that access the price determinationsystem 115 via the telephone, accessing the correct information for agiven encounter may be achieved quickly and easily by dialing theprovided telephone number.

FIG. 1 depicts examples of three types of parties or entities that mayhold full or partial responsibility for payment of a payment amountcalculated by the price determination system 115. However, as will befamiliar to one of ordinary skill in the art, other types and examplesof parties and entities desiring information about the calculatedpayment amount and payment responsibility apportionment determined bythe price determination system 115 may also be incorporated in thesystem and are also envisioned in embodiments of the system described.

FIG. 1 depicts the client-specific data 120 and the price calculationdata 125 that is used by the price determination system 115 as beingstored within the price determination system 115. However, as will befamiliar to one of ordinary skill in the art, in other embodiments, someor all of the information may be stored in one or more of the parties orentities 190, 192, 195 or in another external data storage facility.Accessing some or all of the client-specific data 120 and/or the pricecalculation data 125 externally may be accomplished using any of avariety of known communications methods, such as, for example, dedicatedhigh-speed and/or high-volume communication lines, telephone networks,wireless data transmission systems, two-way cable systems, customizedcomputer networks, or other data transmission methods. In suchembodiments, client-specific rules instruct the price determinationsystem 115 how and where to access the information desired forcalculating the contracted payment amount and, if applicable, forprocessing the payment amount information in accordance with the benefitcoverage and payment rules 155 of the client group.

FIG. 2A depicts one embodiment of an eligibility list 135 that may beused by the price determination system 115 to access information aboutthe patient's 100 eligibility to receive medical goods and services atthe client group's contracted reduced rates. In some embodiments,possession of the card 205 confers eligibility to participate in themedical plan. In some embodiments, client group members pay monthly foraccess to the benefits of the health plan, and eligibility is determinedon a monthly basis. In other embodiments, eligibility is determinedbased upon other bases, such as, for example, upon continued employmentby a given employer. In some embodiments, membership in the client groupand eligibility for the contracted reduced rates of the medical plan isdemonstrated in ways other than by use of the card 105.

As depicted in FIG. 2A, the eligibility list 135 comprises informationthat identifies the patient 100, such as, for example, a memberidentification number 205 assigned by the health plan. In someembodiments, a member's name is used to identify the member. In someembodiments, membership in the client group may be extended to aneligible patient's 100 family members, and in such embodiments theeligibility list 135 may comprise identifying information about themember who is considered the primary member 210. Information about aneffective start date of eligibility 215 to receive the client group'scontracted reduced rates and a termination date of eligibility 220, ifany exists, may also be stored in the eligibility list 135 and may beused by the price determination system 115 for verifying eligibility andfor calculating the contracted payment amount for the patient encounter.

In embodiments where one or more parties or entities other than thepatient 100 in the provider's office 110 is responsible for paying atleast a portion of the payment amount, the price determination system115 may also use information in the eligibility list 135 to correctlyapportion responsibility for the payment. In such embodiments, theeligibility list 135 may also comprise additional information, such as,for example, a balance amount remaining towards a medical plan'srequired deductible amount 225 and a history 230 of medical claims orother information useful for calculating and apportioning responsibilityfor a contracted payment amount. Information in the eligibility list 135may be updated as best suits the needs of the client group, and invarious embodiments, the eligibility list 135 is updated daily, weekly,or monthly.

FIG. 2B depicts one embodiment of a provider list 140 that may be usedby the price determination system 115 to determine with which PPO's theprovider 110 is affiliated and to verify that the provider 110 isaffiliated with at least one of the PPO's that comprise the medical planfor the client group. The provider list 140 may also be used to identifya bank account 112 associated with the provider 110 into which funds aspayment for contracted payment amounts may be deposited. The providerlist may also store and provide other provider-related information asdesired by the individual client groups.

As depicted in FIG. 2B, the provider list 140 comprises identifyinginformation 235, which in FIG. 2B is embodied as the providers' taxidentification numbers. Identification information can also be embodiedin different forms, and in some embodiments, the provider list 140stores identification for the provider 110 as well as for a group, suchas a hospital or doctor's group, to which the provider 110 belongs. Bankaccount information 241 allows for direct deposit of payment amounts inthe provider's bank account 112, and zip code information 242 allows foraccurate calculation of the payment amount when it is based, all or inpart, on the provider's geographic location. The provider list 140 alsocomprises a list of the PPO affiliations 240 for each provider 110,which is used by the price determination system 115, in conjunction withthe priority list 145 that will be described with reference to FIG. 2C,to identify an appropriate PPO whose fee schedule 150 will be used tocalculate the contracted payment amount, as will be described in greaterdetail below with respect to FIGS. 3 and 5.

As was described above, a medical plan may comprise fee schedules 150that have been negotiated with providers 110 by a plurality of PPO's. Aswas also described above, a provider 110 is often affiliated with aplurality of PPO's and may have contracted with different PPO's toprovide goods and services at varying rates. In one embodiment, in orderto know which contracted payment rate applies to goods or servicesoffered by a provider 110 to a patient in a given client group, theclient group builds its medical plan as a hierarchy of PPO fee schedules150 that is encoded in the priority list 145. Thus, a PPO in the healthplan is assigned a ranking, and providers 110 who serve patients 100 inthe client group agree to accept the fee schedule negotiated with thehealth plan's top-ranking PPO, if the provider 110 is affiliated withthe top-ranking PPO, and otherwise with the highest-ranking PPO withwhich the provider 110 is affiliated.

FIG. 2C depicts one embodiment of a priority list 145 that is used bythe price determination system 115 to determine which fee schedule 150to use for calculating the contracted payment amount. As depicted in theexample in FIG. 2C, the priority list 145 comprises the list of PPO's250 whose fee schedules are used by the health plan, as well as aranking 245 for each PPO. Using the priority list 145, along with anyapplicable rules from the client-specific benefit coverage and paymentrules 155, allows the price determination system 115 to know what feeschedule 150 to use to calculate a payment amount when the provider 110is affiliated with more than one PPO, as is often the case.

In some embodiments, the PPO affiliations 240 associated with a givenprovider identification 235 are organized in an ordered format. Forexample, in embodiments where the PPO's in the PPO affiliation list 240are listed by business name, the PPO's may be listed alphabetically bybusiness name. In embodiments where the PPO's in the list 240 are givenan identification number, the PPO's in the list can be listed, forexample, in ascending or descending numerical order. In the embodimentshown in FIG. 2B, the PPO's are identified by alphanumeric code names(for example, PPO-1, PPO-2), and the lists of PPO affiliations 240 areordered in ascending order of the numeric portion of the code names.Thus, the PPO affiliation list 240 for the provider 110 with taxidentification number “22-222-22” begins with PPO-2, PPO-7, and PPO-22.The PPO affiliation list 240 for the provider 110 with taxidentification number “44-444-44” begins with PPO-2, PPO-3, and PPO-7.In other embodiments, the PPO affiliations list 240 may be stored in anunordered format. The PPO affiliations list 240 for provider “22-222-22”is compared with the ranked list of PPO's 250 in the priority list 145to ascertain the highest ranking PPO amongst the affiliates of provider“22-222-22.” In the priority list 145 of FIG. 2C, the top ranking PPO isPPO-3, follow next by PPO-2 in second place, and PPO-7 in third place.

For example, to continue with our example of provider “22-222-22” fromFIGS. 2B and 2C, in one embodiment, the PPO affiliations 240 from theprovider list 140 are searched first for the presence of the top-rankingPPO. In this example, the top ranking PPO in the priority list is PPO-3,and the PPO affiliations list 240 for provider “22-222-22” can besearched for the presence of a listing for PPO-3.

If the PPO affiliations list 240 is ordered, as it is in FIG. 2B, acomputer-implemented search beginning at the start of the list 240 canattempt to find PPO-3 in the list 240 and can determine, once thelisting for PPO-7 has been reached without encountering a listing forPPO-3, that PPO-3 does not exist in the list 240. Therefore, the searchfor PPO-3, the highest ranking PPO in the priority list 145, among thePPO affiliations 240 of provider “22-222-22” need not be continued.

If the PPO affiliations list 240 is unordered, then acomputer-implemented search can be made of the entire list 240, to seeif PPO-3 is present in the list.

If a search determines that the highest-ranking PPO is not presentamongst the affiliations 240 of provider “22-222-22,” then a new searchcan be initiated, this time for the second-ranking PPO from the prioritylist. In the examples of FIG. 2C, the second-ranking PPO is PPO-2, and asearch of the PPO affiliations list 240 for provider “22-222-22” revealsthat PPO-2 is amongst the PPO's listed for provider “22-222-22.” Thus,PPO-2 is the highest-ranking PPO affiliation for provider “22-222-22,”and the fee schedule 150 associated with PPO-2 will be used to determinethe negotiated payment amount for the encounter.

Continuing with the example embodiments of FIGS. 2B and 2C, if theprovider 110 with tax identification number “44-444-44” submits a pricedetermination request to the same health plan for an identicalencounter, the PPO-2 fee schedule 150 is not used, although provider“44-444-44” is also affiliated with PPO-2. The fee schedule 150 forPPO-3 is used, because when the PPO affiliations for provider“44-444-44” are searched for PPO-3, the highest-ranking PPO in thepriority list 145, the search reveals that provider “44-444-44” isaffiliated with PPO-3. Thus, PPO-3 is the highest-ranking PPO in thehealth plan with which provider “44-444-44” is affiliated, and the feeschedule for PPO-3 is used to determine the negotiated payment amountfor the encounter.

Each client group's health plan may comprise a different set of PPO feeschedules and may order them in a different hierarchy. Thus, provider“22-222-22” and provider “44-444-44” may submit price determinationrequests for the same encounters as in the first example above toanother client group's health plan, and may have their negotiatedpayment amounts calculated according to different fee schedules thanthose that were used in the first example. For example, if a healthplan's priority list 145 comprises PPO-7, PPO-22, and PPO-45 as thethree top-ranked PPO's, then a search of the affiliated PPO lists 240for provider “22-222-22” and for provider “44-444-44” reveals that theyboth are affiliated with PPO-7, and they will thus both have theirpayment amounts calculated using the fee schedule 150 of PPO-7.

In another embodiment of a priority list 145, the list 145 for a givenhealth plan may provide a ranking that is geographically based. Forexample, the priority list 145 may specify, for providers 110 in ageographical area defined by a grouping of postal zip codes, that acertain ranking of PPO's be used for selecting a fee schedule 150, whilefor providers 110 in another geographical area, defined by a differentgrouping of postal zip codes, another ranking of the PPO's be used toselect the fee schedule 150. This type of geographically-based prioritylist 145 can reflect the fact that many PPO's are also geographicallybased, which is to say that they represent a network of providers withina limited geographical area, rather than being a national network withproviders spread across the country. Using this type of embodiment, ahealth plan can, for example, structure its priority list 145 to alwaysgive highest ranking to locally based PPO's. When a provider 110requests a price determination, the priority list 145 is consulted usingthe provider's 110 zip code in order to access the health plan's rankingof PPO's for that zip code. Thus, the highest-ranking PPO amongst theprovider's 110 PPO affiliations 240 can be ascertained, and theappropriate fee schedule 150 for the price calculation can be located.

In another embodiment, in locations where such a health plan structureis permissible by law, a health plan may structure its priority list 145to select the PPO fee schedule 150 that reflects the lowest cost to thepatient or other payor. In such an embodiment, the priority list 145 maybe organized by CPT code, such that for a given CPT code, or grouping ofCPT codes, a ranked priority list 145 of PPO's is provided to reflectthe PPO's that have negotiated the lowest payment amount for the givenservices or goods. With this type of embodiment, when a provider 110requests a price determination, the priority list 145 is consulted usingthe CPT code identified by the provider 110 as describing the patientencounter for which pricing is requested. Thus, the health plan'scost-based ranking of PPO's for the given service or goods can be usedto determine the appropriate fee schedule 150 to use for the paymentamount calculation.

Three embodiments of PPO hierarchies and their associated priority listshave been described as examples. Other hierarchy systems are possibleand priority lists 145 to suit the hierarchy systems can be created, aswill be appreciated by one of ordinary skill in the art.

FIGS. 2A, 2B, and 2C depict examples of data structures that can be usedto store data for the price determination system 115. However, the dataused by the price determination system 115 may also be stored as othertypes of flat files, as relational or object-oriented data structures,or as other appropriate structures. As will be familiar to one ofordinary skill in the art, the structure, organization, and content ofthe data may be embodied in different forms to serve the variousembodiments of the medical payment system, without departing from thespirit of the medical payment system described herein. In someembodiments, some or all of the eligibility list 135, the provider list140, and the priority list 145 are implemented as computer modules.

FIG. 3 is a flowchart that depicts one embodiment of a medical paymentsystem 300 that allows a medical provider 110 to contact a pricedetermination system 115 and to receive from the price determinationsystem 115 the correct negotiated payment amount for a patientencounter. From a start state, the medical payment system 300 proceedsto state 310, in which the medical provider 110 contacts the pricedetermination system 115. In one embodiment, the provider 110 contactsthe price determination system 115 by dialing a phone number printed onthe patient's 100 medical plan card 105 and by thereby being connectedto an interactive voice response system (IVRS) associated with the pricedetermination system 115. In one embodiment, the telephone number is notprinted on the medical plan card 105, and the provider 110 has access tothe number for connecting to the IVRS from another source. In oneembodiment, the provider 110 contacts the price determination system 115by dialing a phone number printed on the patient's 100 medical plan card105 and speaking to an operator. In one embodiment, the provider 110contacts the price determination system 115 using a computer network. Inother embodiments, other methods of communication, such as dedicatedphone lines or wireless communications systems, are used by the provider110 to contact the price determination system 115.

Moving on to state 320, once the medical provider 110 has contacted theprice determination system 115, the medical provider 110 inputsinformation about the patient encounter for which the provider 110wishes to receive a contracted payment amount. In one embodiment wherethe provider 110 has contacted the price determination system's 115 IVRSvia telephone, the provider 110 is prompted by oral instructionstransmitted from the IVRS to input the patient encounter informationusing the keypad on the telephone. In one embodiment, the IVRS promptsthe provider 110 to input the patient encounter information orally, andthe price determination system 115 uses a voice recognition system toencode the information into a format usable by the price determinationsystem 115. In other embodiments, the provider 110 inputs the patientencounter information using a computer keyboard or other computer inputsystem. FIG. 4 describes in greater detail one embodiment of anencounter information input system.

Moving on to state 330, once the medical provider 110 has input thepatient encounter information, the price determination system 115identifies the appropriate fee schedule for the encounter. In state 340,the price determination system 115 uses information from the identifiedfee schedule to calculate the contracted payment amount for theencounter. The actions of states 330 and 340 are described in greaterdetail with reference to FIG. 5 below.

Moving on to state 350, once the price determination system 115 hascalculated the contracted payment amount for the encounter, the pricedetermination system 115 communicates the payment amount to the provider110 and to any parties or entities responsible for paying the provider,as indicated by the benefit coverage and payment rules 155 that weredescribed with reference to FIG. 1. In one embodiment, where theprovider 110 communicates with the price determination system 115 usingan IVRS, the price determination system 115 transmits an oral messageover the telephone, informing the provider 110 of the payment amount. Inone embodiment, the price determination system 115 may also offer anoption of having a record of the calculated payment amount faxed to theprovider's office 110 so that the provider 110 can have a paper copy ofthe information exchanged and the calculated payment amount.

Communicating the calculated payment amount to the provider's office 110at the time of service allows the provider 110 to present an accuratebill for the encounter to the patient 100 at the time of service,thereby enabling the patient 100 to pay the provider 110 before leavingthe office. This capability represents a great improvement over currentmedical payment systems in which the provider 110 may typically waitthree to six months to receive payment for an encounter. In oneembodiment, as a condition of receiving the medical plan card 205 andaccess to the reduced rates that it represents, the patient 100 agreesto pay his or her portion of the calculated payment amount, in full oras otherwise agreed upon with the provider 110, at the time of service.

When one or more parties or entities, such as, for example, a thirdparty payor 190, a purse 192, or a medical credit card account 195, isresponsible for paying all or part of a calculated payment amount, theprice determination system 115 may be instructed by the benefit coverageand payment rules 155 to submit a claim or a notification to the one ormore responsible parties or entities. Communication with the responsibleparties or entities 190, 192, 195 may take place via a dedicatedhigh-speed, high-volume data line, via telephone connection, viacomputer network connection, or via another communications method.Instructions regarding the content of the claim or notificationcommunication may be provided to the price determination system 115 bythe benefit coverage and payment rules 155, so that the pricedetermination system 115 is able to accommodate a variety of types ofresponsible parties and entities 190, 192, 195. When instructed by thebenefit coverage and payment rules 155, the price determination system115 can wait for feedback, such as a confirmation, from the responsibleparties or entities 190, 192, 195 and can transmit an appropriatemessage to the provider's office 110 using the IVRS, the fax, or otherchosen communications method. Such an appropriate message may, in someembodiments, be a simple confirmation of the actions taken by the pricedetermination system 115, and may, in some embodiments, provideinformation about a portion of the payment amount still remaining forthe patient 100 to pay.

Other embodiments can allow the price determination system 115 toprocess the calculated payment amount in different ways. In oneembodiment, claims for submission to responsible parties 190, 192, 195for payment are batched and are sent to the responsible parties once aday, or as is otherwise deemed desirable. In one embodiment, informationis stored in a table with the client-specific data 120 that describes aprice determination request for a given encounter and information aboutthe amount of savings received by the patient 100 over the provider'sstandard billing rate for the encounter. Such information may beprovided to the client group or to another interested, authorized partyfor assessing the value of the medical plan to its members.

The flowchart of FIG. 3 has depicted one embodiment of a medical paymentsystem. As will be clear to one of ordinary sill in the art, otherembodiments of the medical payment system may be implemented thatarrange the states of the system in other configurations, that add ordelete states as appropriate, that divide the system into differentstates, or that exhibit a combination of these changes without departingin spirit from the medical payment system described herein.

FIG. 4 presents a flowchart that depicts one embodiment of aninteractive voice response system (IVRS) 400 that can be used by a pricedetermination system 115 to receive encounter information from aprovider 110 and to transmit an associated calculated payment amountback to the provider 110 and, if appropriate, to other associatedparties and/or entities 190, 192, 195.

In one embodiment, communication from the provider 110 to the IVRS 400is carried out using a touch-tone telephone keypad, and communicationfrom the IVRS 400 to the provider 110 is carried out by recorded voicemessages. Allowing the provider 110 to use the telephone keypad to enterthe encounter information, which, in one embodiment, is encodednumerically, provides an accurate, quick, and easy-to-use method forinputting the encounter information. Using the keypad to enter encounterinformation draws upon knowledge that is common to workers in a medicalprovider's office 110 and does not require computer literacy or computerequipment on the part of the provider 110. Configuring the IVRS 400 tocommunicate verbally with the provider 110 in order to convey bothinstructions for use of the system and the calculated payment amountprovides a familiar, easily understandable method for communicating withthe provider 110. In one embodiment, additional communication from theIVRS 400 to the provider 110 may be carried out by fax transmission,especially at the end of the price determination for providing a summaryin printed format of the price determination for the encounter.

In other embodiments, other methods of communication may be implementedfor communications from the provider 110 to the price determinationsystem 115, from the price determination system 115 to the provider, andfrom the price determination system 115 to any other relevant party orentity 190, 192, 195.

For the embodiment depicted in FIG. 4, beginning at state 402, the IVRS400 greets the provider 110. Moving on to state 406, the IVRS 400prompts the provider to enter the patient's 100 member identificationnumber. In one embodiment, the patient's 100 member identificationnumber is assigned by the client group's health plan and is printed onthe patient's 100 medical plan card 105. In one embodiment, the IVRS 400prompts the provider to enter identifying information other than amember identification number for the patient 100. Having access toidentifying information for the patient 100 allows the pricedetermination system 115 to verify the patient's 100 eligibility for themedical plan and, where applicable, allows the system 115 to accessinformation about the patient's deductible balance remaining and priorclaim history or other relevant patient-specific information.

Moving on to state 410, the IVRS 400 prompts the provider 110 to enteridentifying information for the provider 110. In the embodiment shown inFIG. 4, the provider's federal tax identification number is used as areadily available and standard-formatted identifier. In otherembodiments, other forms of identification may be used for identifyingthe provider 110. Identifying the provider 110 allows the pricedetermination system 115 to access information about the provider's 110PPO affiliations, the provider's bank account information 112, and theprovider's contact information, geographic location, and other relevantprovider-specific information.

In the embodiment shown in FIG. 4, the IVRS 400 proceeds to state 414,where the patient 100 identification information and the provider 110identification information are sent to a host processor. In embodimentswhere the telephone number dialed by the provider 110 automaticallyconnects the provider 110 to the client-specific data 120 indexed by theclient group access number 130, having the patient 100 identificationinformation allows the processor to begin accessing stored data that isused to verify patient 100 eligibility, so that the provider 110 can benotified promptly if the patient 100 is determined not to be eligiblefor the benefits of the client group's health plan.

Being connected to the client-specific data 120 also allows theprocessor to access the health plan's hierarchy of PPO's, as expressedin its priority list 145. Based on the type of PPO hierarchy used by thehealth plan, having the provider 110 identification information mayallow the processor to begin locating the fee schedule 150 that will beused by the price determination 115 system for calculating the paymentamount. For example, for health plans with PPO hierarchies similar tothe example illustrated in FIG. 2C, having access to the provider 110identification information allows the price determination system 115 togain access to the provider's 110 list of PPO affiliations 240.Comparing this list 240 to the priority list 145 allows the pricedetermination system 115 to identify the appropriate fee schedule 150.

In one embodiment, to identify the appropriate fee schedule 150, theprice determination system 115 determines if the health plan'shighest-ranking PPO is among the provider's 110 affiliates. If so, theprocessor locates and loads the associated fee schedule 150. If not, theprice determination system 115 identifies the second-ranking PPO in thehealth plan's priority list 145 and once again makes a comparison withthe provider's 110 PPO affiliations list 240. The price determinationsystem 115 determines if the second-ranking PPO is the amongst theprovider's affiliates. If so, the second-ranking PPO is therefore thehighest ranking PPO available amongst the provider's 110 affiliations240, and its fee schedule 150 is used for price determination. If it isnot, this search process continues until the highest-ranked PPO that isboth on the priority list 145 and on the provider's PPO affiliation list120 is located.

Once the appropriate fee schedule 150 is identified, the pricedetermination system 115 can already, “in the background,” access thefee schedule 150, which will be used to calculate a payment amount forany procedure codes entered for the encounter. Fee schedules 150, whichtypically comprise a large volume of complex data, can sometimes beunwieldy and slow to load, and loading the fee schedule “in thebackground” while the provider 110 continues to communicate with theIVRS thus enhances the response speed of the system.

Other embodiments of the priority list 145 also allow for an “in thebackground” loading of the fee schedule.

For example, in embodiments where the PPO hierarchy isgeographically-based, and where the provider list 140 comprises zip codeinformation 242 for the provider 110, having access to the provideridentification 235 allows the price determination system 115 toascertain the provider's zip code 242 and to use that information tolocate the associated PPO priority list 145. As with the previousexample, having access to the priority list 145 and to the provider's110 list of PPO affiliations 240 allows the price determination system115 to identify the appropriate fee schedule 150.

In one embodiment in which the priority list 145 is based at least inpart on the CPT codes entered by the provider 110, locating and loadingthe appropriate fee schedule 150 is deferred until CPT information isentered that will allow the appropriate fee schedule 150 to be located.

Moving on to state 418, in the embodiment shown in FIG. 4, the IVRS 400prompts the provider 110 to enter information about a medical diagnosisassociated with the encounter. One commonly used numeric code forcommunicating about medical diagnoses is called the InternationalClassification of Diseases (9^(th) Edition) code (ICD-9), and in oneembodiment, the diagnosis information is entered using an ICD-9 code. Inone embodiment, providing the price determination system 115 withinformation about the diagnosis associated with the encounter allows thesystem 115 to accurately determine coverage and payment levels forclaims, such as medical insurance claims, that are based at least inpart on diagnosis information.

Moving on to state 422, the IVRS 400 determines whether or not the hostwas able to locate the appropriate fee schedule 150 for the encounter.If the appropriate fee schedule 150 was not found, the IVRS 400 proceedsto state 426, where the provider 110 is transferred to a live customerservice representative for completion of the price determinationrequest. If the appropriate fee schedule 150 has been located, the IVRS400 proceeds to state 430 where the fee schedule 150 is accessed.

Moving on to state 437, the IVRS 400 prompts the provider 110 to enterinformation about a medical good or service associated with the patientencounter. One commonly used numeric code for communicating aboutmedical goods and services is the Common Procedure Terminology (CPT)code. A CPT Modifier Code for use in conjunction with the CPT code canbe used to expand the expressive capabilities of the CPT codes. In oneembodiment, the medical goods or services information is entered using aCPT code and, if desired, a CPT modifier code. Providing the pricedetermination system 115 with information about the medical goods orservices associated with the encounter allows the system 115 toaccurately determine a contracted payment amount.

In the embodiment shown in FIG. 4, the IVRS 400 prompts the provider 110to enter additional information in response to inputted CPT codes forprocedures associated with surgery, anesthesia, laboratory work, andradiology, as is described with reference to states 438-444. CPT codesare often grouped numerically into five classes that allow for easyidentification of surgery, anesthesiology, laboratory, and radiologyprocedures. In other embodiments, other CPT codes may receive specialtreatment, as suits the preferences of the client group's medical plan.

Referring first to state 438, the IVRS 400 determines if the CPT codeentered by the provider 110 in state 437 is a surgery code. If the CPTcode is determined to be a surgery code, the IVRS 400 proceeds to state439, where the provider 110 is prompted to indicate if the surgery is anassisted surgery. In one embodiment, if the provider 110 indicates thatthe surgery was assisted, meaning that the provider 110 served as anassistant surgeon in the surgery, then the price determination system115 is given this information. In one embodiment, the information isrequested because an assistant surgeon is typically compensated at apercentage of the allowed payment amount for the primary surgeon. Instate 440, the provider 110 is prompted to enter the provider's standardbilled amount for the surgery, rounded to the nearest dollar, and theIVRS 400 proceeds to state 445, where the provider is prompted toindicate whether there are more CPT codes to enter in association withthis encounter.

Returning to state 439, if the provider 110 responds that there aremultiple surgery codes to enter, then the IVRS 400 proceeds to state445, where the IVRS 400 cycles back to state 437 and the provider 110 isprompted to enter another CPT code. In one embodiment, the pricedetermination system 115 has been alerted at this point that subsequentsurgery codes entered are for secondary surgeries performed inconjunction with a primary surgery, because secondary surgeries aretypically compensated at a lower payment amount than primary surgeries.

If, in state 438, the IVRS 400 determines that the CPT code entered instate 437 is not a surgery code, the IVRS 400 proceeds to state 441,where the IVRS 400 determines if the CPT code entered in state 437 is ananesthesia code. If the CPT code is determined to be an anesthesia code,the IVRS 400 proceeds to state 442, where the provider 110 is promptedto enter the length of time of the anesthesia procedure in wholeminutes. Entering the time length for the anesthesia procedure can beaccomplished easily using a telephone keypad and allows for propercalculation of the contracted payment amount for an anesthesiaprocedure.

If, in state 441, the IVRS 400 determines that the CPT code entered instate 437 is not an anesthesia code, the IVRS 400 proceeds to state 443,where the IVRS 400 determines if the CPT code entered in state 437 is alaboratory or radiology code. If the CPT code is determined to be alaboratory or radiology code, the IVRS 400 proceeds to state 444, wherethe provider 110 is prompted to indicate by means of CPT modifier code165, whether the price determination request is for service rendered bya technician, such as a blood draw, which is considered a “technicalcomponent” and is compensated at one rate, or is for service rendered bya physician, such as analysis of blood test results, which is known as a“professional component” and is compensated at another rate.

If, in state 443, the IVRS 400 determines that the CPT code entered instate 437 is not a laboratory or radiology code, the IVRS 400 proceedsto state 445, where the IVRS 400 prompts the provider 110 to indicatewhether the provider 110 has more CPT codes to enter in association withthe patient encounter for which a payment amount is being requested.

If, in state 445, the provider 110 indicates that there are additionalCPT codes to be entered in conjunction with the payment amountcalculation request for the current patient encounter, the IVRS 400returns to state 437 where the IVRS 400 prompts the provider 110 toenter a CPT code. The IVRS 400 continues to cycle through states 437-445until the provider 110 indicates that there are no further CPT codes toenter in association with the current payment amount request.

When, in state 445, the provider 110 indicates that there are no furtherCPT codes to enter in association with the current payment amountrequest, the IVRS 400 proceeds to state 470, where the IVRS 400transmits the information that was received from the provider 110 aboutthe patient 100, the provider 110, the diagnosis (ICD-9), and the goodsand services (CPT's) associated with the encounter to a host processorfor the price determination system 115.

In one embodiment, the IVRS 400 proceeds to state 474 where the IVRS 400plays a message indicating the calculated pricing information to theprovider 110 over the telephone. In the embodiment shown in FIG. 4, theIVRS 400 may additionally or alternatively fax the calculated pricinginformation to the provider 110.

Moving on to state 478, the price determination system 115 sends thecalculated payment information and any associated information indicatedby the benefit coverage and payment rules 155 to any responsible partiesand/or entities indicated in the benefit coverage and payment rules 155as was described with reference to FIG. 1.

Moving on to state 482, the IVRS 400 prompts the provider 110 toindicate whether there are more claims to price for this patient. If theprovider 110 indicates that there are one or more claims to price, theIVRS 400 proceeds to state 437, where the provider 110 is again promptedto enter a CPT code and to proceed as was described above. If, in state482, the provider 110 indicates that there are no more claims to pricefor the patient 100, the IVRS proceeds to state 486, where the IVRS 400indicates to the provider 400 that the interaction is completed, and thecommunication is terminated.

The flowchart of FIG. 4 depicts one embodiment of an encounterinformation input system. As will be clear to one of ordinary skill inthe art, other embodiments of the encounter information input system maybe implemented that arrange the states of the system in otherconfigurations, that add or delete states as appropriate, that dividethe system into different states, or that exhibit a combination of thesechanges without departing in spirit from the encounter information inputsystem described herein.

FIG. 5 is a flowchart that depicts one embodiment of a method 500 thatcan be carried out by a price determination system 115 to determine acontracted payment amount for a patient encounter. The embodiment shownin FIG. 5 corresponds generally to states 330 and 340 of the medicalpayment system 300 described with reference to FIG. 3 above.

The method 500 of FIG. 5 begins in state 510 where the pricedetermination system 115 verifies the eligibility of the patient 100 toreceive the benefits of the medical plan associated with the clientgroup access number 130. In one embodiment, the price determinationsystem 115 accepts member identification information about the patient100 from the provider 110 and uses the identification information toaccess eligibility information about the patient 100 stored in aneligibility list 135, as was described in greater detail with referenceto FIG. 2A. For example, in embodiments in which information about thepatient's effective date 215 of coverage and termination date 220 isstored in the eligibility list 135, the price determination system 115verifies that the current date is later than the effective date 215 andthat the current date is earlier than the termination date 220, if anytermination date 220 is listed.

Once the price determination system 115 determines that the patient 100is eligible to receive the benefits of the medical plan, the pricedetermination system 115 proceeds to state 520 of the method 500, inwhich the price determination system 115 uses the medical provider 110identification information entered by the provider 100 to identify theprovider's 100 PPO affiliations. In one embodiment, the pricedetermination system 115 uses the provider list 140, as was described ingreater detail with reference to FIG. 2B, to identify the provider's 110PPO affiliations.

Proceeding on to state 530 of the method 500, the price determinationsystem 115 uses the PPO affiliation information accessed in state 520together with information stored in the priority list 145, as wasdescribed in greater detail with reference to FIG. 2C, to identify whichof the provider's 100 affiliated PPO's is given the highest priorityaccording to the priority list 145. This information can be used toidentify the fee schedule 150 that is to be used for calculating thepayment amount. Basically, the PPO affiliations negotiated by theprovider 110 are identified, the hierarchy of the health plan's PPO's isidentified, and the two are compared in order to determine which of thePPO's affiliated with the provider 110 has the highest ranking in thehealth plan's hierarchy.

In various embodiments, identifying which of the provider's 110affiliated PPO's is given the highest priority can be carried out indifferent ways, depending on the organization, structure, and content ofthe priority list 145 and of the list of PPO affiliations 240 for eachprovider 110. For example, whether the provider's 110 PPO affiliationsare stored in an ordered or an unordered format, as well as the type ofdata structure used for their storage, will affect the method used forsearching for and locating the given provider's 110 most highly-rankedPPO, as will be familiar to a practitioner of ordinary skill in the art.One simple example of such a search was described with reference toFIGS. 2B and 2C.

Furthermore, the type of hierarchical organization of PPO's that is usedto form the client group's health plan will affect the method used instate 530 to determine which PPO's fee schedule 150 is to be used forcalculating the payment amount due to the provider 110.

For example, as was described with reference to FIG. 2C, in embodimentswhere the health plan is organized such that for each geographicallocation served, a different ranking of the PPO's is used, thensearching for the highest-ranking PPO may comprise identifying the zipcode 242 associated with the provider 110 and identifying the portion ofthe priority list 145 associated with that zip code.

In other embodiments, one ranking of PPO's may be used for allgeographical areas except for one area, in which, for example, aself-insuring employer has negotiated special rates with medicalproviders and for which another ranking exists. In such an embodiment,the benefit coverage and payment rules 155 may instruct the pricedetermination system 115 to use the zip code 242 of the provider 110 whois submitting a price determination request to access the desiredranking of PPO's in the priority list 145.

As was also described with reference to FIG. 2C, in some embodimentswhere such arrangements are permissible, the health plan is organizedsuch that the payment amount negotiated by the PPO that offers thelowest price for the services or goods associated with the patientencounter is the amount used as the contracted amount. In suchembodiments, searching for and locating the appropriate fee schedulecomprises identifying the CPT code or other procedure/goods identifierassociated with the patient encounter and identifying the portion of thefee schedule 150 that gives a ranking of PPO's for that procedureidentifier.

Procedure identifiers such as CPT codes may also be relevant to thesearch for an appropriate fee schedule 150 in embodiments where a givenPPO does not provide a negotiated rate for the services or goodsassociated with the patient encounter. For example, a given PPO may nothave negotiated a payment amount for eye examinations with itsaffiliated providers. Thus, even if the given PPO is listed in thepriority list 145 as having the highest ranking in general, for patientencounters that involve an eye examination, the fee schedule associatedwith the PPO that has the next highest ranking and that does provide acontracted rate for eye examinations will be used. As will be familiarto a practitioner of ordinary skill in the art, the priority list 145can be modified to express such a hierarchy.

Other embodiments may use other methods and information sources tosearch for an appropriate fee schedule, as encoded in the instructionsof the benefit coverage and payment rules 155. For example, in oneembodiment, a client group may choose to give the highest ranking to thePPO, from amongst those that make up its health plan, that contractswith the largest number of providers, and to rank the other PPO's in itshealth plan according to the number of providers in their network, aswell. Information about the number of contracted providers participatingin each PPO's network may be provided to the price determination system115 on a daily, weekly, monthly, yearly or other basis, so that thepriority list 145 in such an embodiment may be kept up-to-date.

Handling exceptions and anomalies in the selection of fee schedule 150for use in price determination can be carried out in a variety of ways,as expressed by the benefit coverage and payment rules 155 for a givenclient group. In some embodiments, if a provider 110 does not appear inthe client group's provider list 140, or if the identified provider 110has no associated PPO affiliations that appear in the priority list 145,then the price determination request submitted by telephone, computer,or other communications method is forwarded to a human representativefor price determination. In some embodiments, the price determinationrequest is rejected, and a message is transmitted to the provider'soffice 110 that no payment amount for the encounter can be calculatedusing the price determination system 115.

In some embodiments, the benefit coverage and payment rules 155 for agiven client group specify a default method of handling such anomaliesor exceptions. In one embodiment, a default flat fee for each CPT codemay be specified. In another embodiment, a fixed percentage of theprovider's standard billing rate for the given service or good may bespecified. In such an embodiment, the IVRS or other communicationsmethod may need to prompt the provider 110 to enter the standard billingrate for the given service or good. In other embodiments, exceptions andanomalies are handled using other methods that will be familiar to oneof ordinary skill in the art.

Proceeding to state 540 of the method 500, the price determinationsystem 115 accesses the fee schedule 150 for the PPO that was identifiedin state 530 as being the PPO with the highest priority from amongst theprovider's 110 PPO affiliations. In one embodiment, the pricedetermination system 115 uses the fee schedule 150 to determine thecontracted calculation methodology agreed upon by the provider 110 andthe provider's highest priority PPO for the medical goods and/orservices with the CPT codes input by the provider 110 for the patientencounter.

Once the calculation methodology agreed upon by the provider 110 and bythe PPO has been identified, the price determination system 115 proceedsto state 550 of the method 500 and uses the identified calculationmethodology to calculate the contracted payment amount for the goods andservices identified by the provider 100 as being associated with thepatient encounter. In some embodiments, the CPT information 160 storedin the price calculation data 125 is accessed to identify the multipliervalues for the entered CPT codes, as was described with reference toFIG. 1. In some embodiments, zip code information 180 and/or Medicarepayment rate information 175 is accessed in order to calculate thecontracted payment amount for the encounter.

Once the contracted payment amount has been calculated, the medicalpayment system 300 of FIG. 3 can use the payment amount informationtogether with information stored in the client group's benefit coverageand payment rules 155 to apportion, amongst one or more parties orentities 100, 190, 192, 195, the responsibility for paying the paymentamount to the provider 110. The medical payment system 300 can furthercommunicate with the one or more parties or entities 100, 190, 192, 195in order to notify them of the portion of the payment amount for whichthey are responsible to pay.

The flowchart of FIG. 5 has depicted one embodiment of a method todetermine a negotiated payment amount for a patient encounter. As willbe clear to one of ordinary skill in the art, other embodiments of thepayment amount determination method may be implemented that arrange thestates of the system in other configurations, that add or delete statesas appropriate, that divide the system into different states, or thatexhibit a combination of these changes without departing in spirit fromthe payment amount determination method described herein.

For ease of explanation, some simplifying assumptions have been made inthe foregoing detailed description. For example, one-to-onecorrespondences have been assumed between the provider 110 and theprovider bank 112, between a client group and the associated medicalplan, and between a PPO and the associated priority list. Thus, forpurposes of this description, for example, sending a payment to aprovider's bank account 112 is equivalent to sending payment directly tothe provider 110. Similarly, for purposes of this description, becausethe aspect of interest with respect to the client group is the medicalplan that it offers its members, the terms client group and medical planmay be used interchangeably in some instances. Furthermore, theone-to-one correspondence assumed in this description for ease ofexplanation implies that a hierarchy or priority list of PPO's may alsobe seen as a hierarchy or priority list of the associated fee schedules.In other embodiments, these one-to-one correspondences may not hold truewithout departing from the spirit of the medical payment systemdescribed herein.

While certain embodiments of the inventions have been described, theseembodiments have been presented by way of example only, and are notintended to limit the scope of the inventions. Indeed, the novel methodsand systems described herein may be embodied in a variety of otherforms; furthermore, various omissions, substitutions and changes in theform of the methods and systems described herein may be made withoutdeparting from the spirit of the inventions. The accompanying claims andtheir equivalents are intended to cover such forms or modifications aswould fall within the scope and spirit of the inventions.

1. A computer system of facilitating payment of health care benefitscomprising: healthcare provider identification information; storing aplurality of fee schedules in computer memory; electronically receivingdata about a healthcare expense associated with a healthcare providerand a patient; and computer hardware configured to: identify a payerthat has agreed to pay the healthcare provider on behalf of the patient;identify one of the plurality of fee schedules that should be used inassociation with the healthcare expense based on eligibility, andpriority in order to identify the healthcare provider's highest-prioritypayer affiliation; calculate a payment amount based at least in part ona fee schedule; electronically verify that the payment amount is a bonafide medical expense; approve the payment amount only when the paymentamount has been verified; and electronically transfer the verificationof the payment amount to an account associated with the patient; andelectronically transmit a copy of the payment amount to the healthcareprovider.
 2. The system of claim 1 wherein the account is a bankaccount.
 3. The system of claim 2 wherein the bank account is associatedwith a card that is at least one of the group consisting of: a storedvalue card, a medical credit card, and a medical plan card.
 4. Thesystem of claim 1 wherein the computer hardware is further configured toapprove multiple payment amounts.
 5. The system of claim 1 wherein thecomputer hardware is further configured to receive and store multiplepayment amounts.
 6. The system of claim 1 wherein the computer hardwareis further configured to process and store multiple payment amountsassociated with multiple patient encounters.
 7. The system of claim 1further comprising an interactive voice response system configured toprompt the healthcare provider to enter information about a patientencounter.
 8. The system of claim 1 further comprising an interactivevoice response system configured to communicate information about theapproval of the payment amount.
 9. The system of claim 1 furthercomprising an interactive voice response system configured tocommunicate information about the account.
 10. The system of claim 1wherein the computer hardware is further configured to determine aportion of the payment amount to be paid by the patient and a portion ofthe payment amount to be paid from a source of medical funds.
 11. Thesystem of claim 10, wherein the source of medical funds is a third-partypayor.
 12. The system of claim 10, wherein the source of medical fundsis a flexible savings account.
 13. A method of facilitating payment ofhealth care benefits to a health care provider comprising: storing aplurality of fee schedules in computer memory; electronically receivingdata about a healthcare expense associated with a healthcare providerand a patient, wherein the healthcare provider renders goods andservices to the patient in anticipation of payment; identify one of theplurality of fee schedules that should be used in association with thehealthcare expense based on eligibility, and priority in order toidentify the healthcare provider's highest-priority payer affiliation;determining with computer hardware, a payment amount associated with thegoods or services wherein determining the payment amount comprisescalculating the payment amount based at least in part on the identifiedschedule; electronically verifying with computer hardware that thepayment amount is a bona fide medical expense; determining with computerhardware a first portion of the payment amount to be paid by the patientand a second portion of the payment amount to be paid from a source ofmedical funds; electronically sending the verification of the paymentamount to an account associated with the patient; electronicallyapproving, the payment amount only when the verification of the paymentamount has been received; and communicating to the patient the firstportion of the payment amount paid by the patient and the second portionof the payment paid by the one or more insurance providers.
 14. Themethod of claim 13 wherein the account is a bank account.
 15. The methodof claim 13 wherein the bank account is associated with a card that isat least one of the group consisting of: a stored value card, a medicalcredit card, and a medical plan card.
 16. The method of claim 13 furthercomprising approving multiple payment amounts.
 17. The method of claim13 further comprising receiving and storing multiple payment amounts.18. The method of claim 13 further comprising processing and storingmultiple payment amounts associated with multiple patient encounters.19. The method of claim 13 further comprising prompting a provider withan interactive voice response system to enter information about apatient encounter.
 20. The method of claim 13, wherein the source ofmedical funds is a third-party payor.
 21. The method of claim 13,wherein the source of medical funds is a flexible savings account.